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1. INTEODUCTION 

The main body of this summary is divided into ten sub- 
sections. This division corresponds closely to the items with- 
in the original scope of work (SQW) of the contract. Generally 
there are two or three consecutive subsections pertaining to 
each SOW item. The exact correspondence between the subsections 
and the SOW items is given in Figure 1-1. 

The original purpose of this contract was to conduct 
exploratory analysis within the individual areas mentioned in 
the scope of work. However, in time the work evolved into the 
design of a software specification and evaluation system. This 
system will be denoted as SSES throughout this report. The 
various techniques and tools which constitute this system are 
the topics of subsections of section two of this report. 




Figure 1-1. Subject ion/SOW/SSES Goal Correspondence 
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2 . SSES METHODOLOGY QjaGTNAL PAG® POOPv 

2.1 GENERAL 

Eight months ago, SAI and NASA jointly began a soft- 
ware research effort to develop methods which will reduce the 
effort expended (usually 50%) in a typical software test and 
verification effort. The initial emphasis was toward developing 
techniques that would allow efficient automatic verification of 
software without a consequent loss in user confidence. Such a 
verification procedure could be constructed to perform consis- 
tently only if stringent demands and checks were put on the soft- 

. , j. 

ware throughout its developihent . The software development stages 
generally are understood to be requirementSV specifications, 
code, test, and maintenance. We cpnGluded that an entire soft- 
ware development methodology would have to be developed to en- 
sure that at no stage of the development could major inconsis- 
tencies remain undetected, and that from requirements onward the 
software product would have to be quite formal. The design of 
our methodology is centered about five goals: 

1. Early Program Feasibility and Testing 

2. Requirements/Specification Completeness and Trace- 
ability 

3. Reliable Code Implementation 

4. Sufficient Test Capability 

5. Sufficient Maintenance Capability 

Achieving these ends demanded the development of a formal soft- 
ware requirements methodology, a formal specifications language 
which could traceably embody requirements, a high level pro- 
gramming language which could be easily and faithfully generated 
from specifications and could promote a logical error-free code 
impioinentation, a language preprocessor to allow compatability 
of the methodology with existing compilers, and finally, auto- 
matic code analysis tools to attain our original objective - 
that of reducing software test and verification effort. The 



way in which these tecliniques wuaid t>e used in a software de- 
velopment project is depicted in Figure 2-1. 

The construction of our unified methodology demanded 
tliat each tool and technique take allowance of the other tech- 
niques which would be employed prior to and following it. Our 
original work goal - the allowance of a reduction in software 
test effort without a corresponding loss in user confidence - 
meant automatic test tools had to he employed and their func- 
tions first had to be defined. After realizing this implication^ 
W(’ cu)nc1 tided that the efficacious performance of these test tools 
niiido r. or tain demands on the programs analyzed and on the yery 
programming language employed. Similarly, program language re- 
Kiri ctlons have placed demands upon the way in which specifica- 
Lions !‘or those programs were to be written; and specification 
ffvstr i c Lions have an impact upon requirements which would give 
rtK(? 1.(5 Lhose specifications. Hence, it was decided that the 
cU'vti I opmont . of our software methodology had to be carried out 
in reverse order from that of software development. 

Such a methodology - an integrated Software Specification 
and Evaluation System (SSES), Is being developed for HASA/MSFC. 
Some SSES components are entirely original - like the software 
specifications language, the data base verifier, and testcase 
gonorator (and indeed the whole integrated sy^stem itself), while 
some are improvements upon already existing technology - like 
the structured programming language and the static analyzer . 

The Executive Summary does not attempt to treat in depth any one 
SSES component but only to present the technical highlights and 
unincation of our software methodology. Detailed discussibns 
of ihe various system components will be the topics of Part II 
or this report. 
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2,2 SOFTWARE IffiQUIEEMENTS METHODOLOGY 

The basis for the software requirements methodology was 
Initiated within the September 18th progress report of this 
contract. Subsections of that report dealing with the software 
requirements decomposition methodology have been edited for 
inclusion below. 

2.2.1 Software Requirements and Traceability 

Our efforts toward the semantic definition of a formal 
software specification language have necessitated an analysis 
of the manner in which software requirements are stated. In 
subsection 2. 2. 1,1, we present Our view of the early develop- 
ment stages which is compatible with currect NASA procedures and 
guidelines. Subsection 2.2. 1.2 discusses requirements decomposi^ 
tion in more detail, listing the necessary elements of a decom- 
position. Subsection 2. 2.1.3 presents an example. The names 
that have been assigned the components are working titles, sub- 
ject to change . 

2.2. 1.1 Introduction 

Requirements analysis is a continuing effort from 
problem recognition to problem statement to solution recommen- 
dation. It is the final phase, solution recommendation, tnat 
is of importance to the process of software module specification. 
In this report, we are not concerned with how the recommendation 
was derived, but only how it is stated. In effect, we are stat- 
ing our assumptipns concerning what information is contained 
within a requirement and recommending a format to make that in- 
formation explicit. To do this requires that we state our view 
of the activities and deliverables associated mth the early 
stages of design. 

Figure 2-2 illustrates the activities and documents cur- 
rently depicted in NASA working papers on software development 
procedures. ( Activities are represented by hexagons). We have 
divided the NASA activity "Preliminary Design" into several sub- 
activities as will be presently explained. 
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Principal documents and activities of the early phases 
of development are:. 

Systems Requirements Specification - A document describ- 
ing the functional and environmental charac- 
teristics of the problem solution. 

Software Requirements Specification - A document which 
describes the software interfaces with the 
environment in which it performs as well as .key 
assumptions and constraints. 

Software Requirements Definition - An activity whose 

purpose is to derive the Software Requirements 
Specification from the Systems Requirements 
Specification . 

Preliminary Software Design Specification - A document 
describing the data structures and software 
functions which will comprise the finished soft- 
ware system. 

Preliminary. Design (PD) - An activity whose purpose is 

to derive the Preliminary Software Design Speci- 
fication. 

Preliminary Software Requirements Decomposition (PSRD) - 
A subactivity of PD whose purpose is the dec- 
laration of the actions to be performed by a 
a single software package; emphasis is on what 
to do and not how (nor how well) to do it. 
Software Requirement Decomposition (SRD) - A subactivity 
of PD whose purpose is the detailed declaration 
the actions to be performed by a single soft- 
ware package arranged in the same general form 
as the PSRD; initial estimates are included that 
pertain to "when" j "how well", and "how" various 
actions are to be performed. 


Subsystem Software Requirement Decomposition (SSRD) - A 
subactivity of PD whose purpose is a declaration 
with the same form and substance as the SRD ex- 
cept it pertains to only one subsystem within 
the software package. 

The next subsection contains a detailed summary of the constit- 
uents of PSRD, SRD, and SSRD. 

2.2. 1.2 Contents of the Software Requirement Documents 

In this subsection, we state in detail the (quite 
similar) PSRD, SRD, and SSRD subactivities- In doing so we 
have included only those facets of a requirement that directly 
affect the software organization. Noticeably absent are such 
requirement categories as: 

9 Manpower and schedules 
9 Applicable documents 

« Acceptance criteria. 

Wo wish to emphasize once more that our purpose is to state the 
information derived from Software Requirement Decomposition and 
not the methodology employed. 

For the purpose of module specification there are two 
types of requirement decomposition suhactivities . The first is 
the Software Requirement Decomposition which is an expansion of 
PSRD. The SRD embraces the recommended solution of the original 
problem obtained , from the customer. The second type is the Sub- 
system Software Requirement Decomposition which nearly always 
expands on a subsystem or real time process derived from the SRD 
or a preceding SSRD. There may be from none to several SSRD 
activities and they are performed by the analyst at any time up 
to the conclusion of detailed design. There will be a broader 
discussion of subsystems within the example of subsection 2. 2, 1,3. 
Within a SRD or SSRD there are seven divisions: 

Direction - A general statement of the boundaries of 
the problem. 
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Transductions - A list of processes to be performed, 
each of which translates a stimulus ' into a 
response . 

Input - Data or documents available to the software 
system from external sources. 

Output - Data or documents produced by the software 
for external purposes. 

Constraints - A list of capabilities, design objectives, 
or resources to be observed. 

Preconceptions - A list of specific design alternatives 
to l>e observed. 

Implications - A binary relation existing between cer- 
tain transductions. 

Of the seven divisions, only the direction and a subset of the 
tran.sductions are required for the Preliminary Software Require- 
ment Decomposition. (The specific subset of the transductions 
neces.sary will be shown in the next subsection). If there are no 
implications, all transductions are assumed to be independent. 
Pigure 2-3 illustrates the relationship between software and sub- 
system requirements for a particular system, 

2. 2. 1.3 A Software Requirements Example 

Assume that an employer wishes to establish a list of 
employees based on proximity of residence for the purpose of 
carpooling. He desires the results compiled in two formats: 

(1) an alphabetical list of employees and their assigned car- 
pool number, and (2) a list of carpools with individual partic- 
ipants. With the aid of an analyst, he derives the following 
Preliminary Software Requirement Decomposition: 

Direction 

Construct carpool lists by individual and by carpool 

number . 
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Figure 2-3. Hequirements Document Structure 





Transductions 


Translate : 
Group ; 
Assign : 
Print 1: 
Print 2: 


Transform each employee street address to 
a uniform coordinate system. 

Cluster employees based on proximity of 
residence. 

Assign each individual to exactly one car- 
pool . 

List individuals alphabetically with car- 
pool assignment . 

List carpools with individuals assigned. 


Completeness and unambiguity is necessary in the above statement, 
but we make no recommendation for attainment other than inspec- 
tion. The form and content are important for the purposes of 
software specification. If desired, it may be expanded via foot- 
notes or appended subparagraphs. Particularly important to this 
problem is a list of available documents such as employee file 
and street /coordinate tape. 

The analyst now assumes primary responsibility and 
attempts to add, perhaps in consultation with the customer, the 
following items; 

« Constraints that are both problem oriented and 
computer oriented 

• Additional transductions that are either implied 
by the original transductions or are made necessary 
by the constraints 

• The implication list 

m The preconception list 

e The input and output lists 


The results of this analysis (which complete Software Require- 
ment Decomposition) are stated below: 


T r-ansductions (Derived from the previous transductions) 

Precord: Print an employee name and address. 

Find: Find the most eligible individual to add to 

an existing carpool- 

Span: Compute the minimum tree span of a set of 

nodes specified via planar coordinates. 

Match: Search the street/coordinate file for the 

nearest point to a given address. 

Reject: Delete all employees for which street name or 

street number is not on coordinate file. 
Sorte: Sort carpool file. 


Input 

Employee file: Name and address of each 

employee. 

Coordinate file: Correlation of street addresses 

with an (x , y)-coordinate system. 


Output 

List 1 : 
List 2; 


Constraints 


An alphabetical list of employees with 
carpool assignments. 

List of carpools with individuals as- 
signed. 


Memory: Use no more than 32K words 

Machine: Use IBM S360/65 for development 

Language: Use ANSI Standard FORTRAN without the 

arithmetic IF 


Size ; 
Distance 


No carpool may contain more than five 
persons 

The sum of the distances associated with the 
edges of a minimum spanning tree of resi- 
dences of members of a single carpool must 
be less than two kilometers. 


:/ 7 / 
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Implications 

Translate 3 Matcli 
Translate ^ Reject 
Assign ^ Find 
Assign 3 Span 


P'rintl 2) Pi^ecord 
Print2 D Precord 
Reject 3 Precord 
Printl 3 Sorte 


Prucioncept ions . ^ 

Sort: Use a shell sort to produce the Print 1 listing 


Presume that the analyst determines that clustering 
should be implemented as. a major independent subsystem. (He/ she 
may make this decision at any point prior to completing the 
design.) The desired subsystem will: 

(1) Cluster the employee file based on proximity of 
residence 

(2) Write the clusters onto a segmented file, one 
cluster per segment 

(3) Sequentially read the cluster file with end of 
segment markers. 


Commensurate with these goals, the analyst next performs the 
SSRD. The results are as follows: 

Direction 

Cluster and order an employee/coordinate file. 


Transductions 

Initialiiie : 


Cluster : 

Restart : 
Segment ; 
Fetch : 


Find the n farthest apart points in the 
file to use as initial cluster centroids; 
n will be an input parameter. 

Match each point in the file to the near- 
est centroid. 

Compute the centroids of each cluster. 
Order clusters into segments and save. 
Fetch the next element of the current 
cluster. 
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Mark: 
Measure : 


Test for end of cluster. 

Find the point nearest a given point from 
a given set of points. 

Swap: Exchange two employee records 

Input 

Point file: A file containing a secjuence of ;X,y)- 

coordinates with a unique identifier 
attached to each 


An entry from the point file 
An end of segment marker 
An end of file marker 


n £ 50 (the number of clusters). 

Continue attempts to cluster until the 
centroids remain unchanged on two con- 
secutive tries. 

Implications 

Measure c Initialize 
Measure Cluster 

Swap G Segment 

Preconceptions 

None 

Tie analyst now embarks upon the second phase of Prelim- 
inary Design, module specification. However, he/she may con- 
tinue to reduce portions of the system to subsystems. Sub- 
systems are similar to levels of abstraction [1] and have four 
distinctive characteristics; 

(1) The modules within a subsystem do not share any 
global data (e.g. , files or COMMON) with modules 
not in the subsystem. 


Output 

Neighbor : 
Eos : 

Eof : 

Constraints 

Number : 
Halt; 
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(2) The modules located at the subsystem entry points 
are referenced (called) only by modules not in 
the subsystem. 

(3) No module referenced (called) directly by a module 
within the subsystem is ever referenced directly 
by modules not in the subsystem. 

(4) All subsystems satisfy one or more of the follow- 
ing criteria: 

(a) Information hiding - The subsystem isolates 
design decisions likely to change. 

(b) Resource management - The subsystem has 
exclusive control of particular resources 
such as a peripheral or data structure, 

(c) Division of labor - The subsystem is logically 
complete, apart from the original require- 
ments, i.e., it is a reuseable component. 

(d) Real time process - The subsystem operates as 
an asynchronous activity within a real time 
application. 
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! Within the cottrse of this contract , a formal language 

was designed for the purpose of conveying the Preliminary Design 
specifications of software. In the following subsections, we 
discuss the purpose, goals, and specific attributes of our Soft- 
ware Specification Language (SSL) as well as provide a simple 
example of how SSL is used. 

2.3.1 Purpose and Goals of SSL 

In the software development process, the step between 
producing software requirements and constructing a detailed 
specification of the code has been informally supported by charts 
and diagrams, procedural languages, descriptive systems, and 
K-diagrams. Therefore, we have developed a software specifica- 
tion language, the function of which is to formally describe the 
overall software system (or functional) structure, and thereby 
provide a firm foundation for the aforementioned software de- 
velopment step. Additionally, SSL fulfills another primary 
goal, the goal of traceable requirements, by incorporating the 
capability to tag requirements and attach them to specific 
software objects. In Table 2-1, the goals for our functional 
specification language are presented along with a brief dis- 
cussion of each goal . 

One of the specified goals in Table 2-1 is "formality.": 
Formality (i.e., rigorous definition) is necessary for auto- 
mation. Specific attributes of SSL that fulfill this general 
goal or attribute are: 

• A context-free grammar representable in 
Backus-Naur Form 

• Semantics that are defined via set theory 
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Table 2-1. Functional Specification Language Goals. 

S pool [Mcations should describe the overall software system 

■structure . 

Functional specifications should provide a link 
between the requirements specification and detailed 
design in terms of a non-procedural description. 

Specifications should be formalized . 

Formalization permits automatic consistency checking, 
restricts the designer to the level of detail appro- 
priate for functional specifications, and improves 
communication between designer (s) and implementer(s) 
and among implementors. 

Specifications should impact reliability . 

A formalized specification system is a step toward 
"designing in" rather than "adding on" reliability 
and can be accomplished by providing feedback to 
requirements for design decisions occurring early 
in the development process. It can assist in ascer- 
taining the correctness of succeeding project devel- 
opment steps rather than relying on external machanisras 
to remove anomalies. 

Specifications should be transparent . 

By "transparent" we mean that no reasonable software 
structure should be rendered impossible to depict 
due to limitations of the language used. Trans- 
parency is necessary so that specification require- 
ments (such as the incorporation of an existing soft- 
ware package) will be possible. 

Specifications should be complete and unambiguous . 

By completeness, it is meant that all objects created 
by the designer are subsequently traceable to a set 
of terminal objects that are provided within the lan- 
guage, Specification ambiguity can arise in structure, 



2-16 


Ta.ble 2-1. Functional Specification Language Goals (con't.) 

if the object interrelationships can be interpreted in 
more than one way, or if the basic oojects of the lan- 
guage are not well defined. 

SpeciilicaLions should have a Uniform level of detail . 

The non-procedural nature of a functional specification 
language will limit the descriptive potential of the 
language to interconnection relationships. 

A specification language should be machine independent . 

Machine dependencies are seldom a desirable level of 
detail. Thus, a specifications language should em- 
phasize conceptual and abstract objects, -although 
recognizable as components of most digital computers. 

Spocifications should depict interfaces simply and clearly . 

In addition to depicting interfaces, the language 
should be organized in a manner that encourages the 
designer to construct simple, smooth connections. A 
specification language should require explicit creation 
and usage declarations of all objects. It should af- 
ford clear and concise rules for assigning attributes 
to each object ..and to delineate scope of access. 

Specifications should be modifiable . 

The degree of ease with which a description can be 
modified is partly a function of how it is used by 
the designer. A specifications language could assist 
by providing mechanisms to isolate and encapsulate 
critical design decisions. A language should provide 
methods for a natural partitioning of the problem 
.space and provide means for the designer to create 
.sub-part i t ions . 


A spec, i r i cat ions language should be easy to use . 

I3y easy to use, we mean readable by higher levels in 
the command chain (managers) and easily communicable 
to imp! omenters . 
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Table 2-1. Functional Specification Language Goals (con’t.) 

Achieving this goal would encourage utilization of the 
methodology, abate clerical errors, assist communi- 
cation, and provide permanent documentation. 

Spoci Fications should reflect error handling requirements . 

When project development schedules are underestimated, 
misjudging the magnitude of error analysis required is 
generally a contributory factor. A specification lan- 
guage should incorporate explicit declarations of nec- 
essary software error checks. 

Specifications should reflect fault tolerant capabilities . 

The term "fault tolerant" means the ability to cope 
with errors by the user and in the environment. As 
in error handling, explicit declarations should 
accompany I/O accesses. 

S pecifications should reflect the original requirements . 

Generally, the more detailed the design, the more 
Isolated the designer is from the original require- 
ments. A formal specification language could alle- 
viate this problem by permitting requirements to be 
labeled and attached as attributes to system objects. 
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Another goal is the enforcement of a uniform level of 
dc'Luil. This is desirable with respect to the top-down program- 
ming philosophy and in assuring that equal attention has been 
given all aspects of the design. Specific SSL attributes that 
are commensurate with this goal are: 

• Utilization of non-procedural language 
constructs only, to focus attention on 
static structure rather than algorithm 
dynamics. 

• . Adoption of the software module as the 

elementary unit of definition; a module 
is one or more compilation units (e.g. , 
subprograms , procedures ) . 

Examining the entire general attribute list provided 
in Table 2-1 confirms that the specific attribute list of SSL 
would be necessarily quite extensive and will therefore not be 
presented in this summary report . A cursory view of SSL is 
given in the next subsection. 

2.3.2 Partitioning of Specifications 

Functional specifications for a software system may be 
divided into three areas; environment, data, and control. SSL 
provides the capability to specify the minimal set of hardware 
characteristics that are inherent in the problem definition and 
that impact software organization (see ACCESS statement in Figure 
2-5 of subsection 2.3.3). In the data area, SSL offers the 
mechanisms to explicitly describe a variety of data structures 
and to specify when the data is used as input (i.e., in the 
USES clauses Illustrated in Figure 2-5 in subsection 2.3.3) or 
as output (i.e., in the CREATES or MODIFIES clause shown in Fig- 
ure 2-5 in subsection 2.3.3). Moreover, SSL is used to describe 
the module/data interconnection structure and a rationale for the 
module/data interconnection structure and a rationale for the 
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structure based on requirements. Regarding the control area, 
SSL is not designed to depict the control flow within modules. 
However, intermodule connections can be depicted by use of the 
liXHCUTLS statement (in Figure 2-5 of subsection 2.3.3) in which 
conditional, iterative, or recursive execution of modules is 
.spciciXied. In addition to providing specifications in these 
areas, SSL ensures that the resulting specifications are suffi- 
ciently abstract to prevent selecting a specific machine repre- 
sentation. 


2.3.3 SSL Subsystem and Module Descriptions 

SSL allows for partitioning the software into subsys- 
tems based on the principle of levels of abstractions. A spec- 
ification in SSL is represented as a set of subsystems which is 
shown in Figure 2-4. Each subsystem is defined by a preamble 
and one or more module descriptions. The preamble describes the 
local environment for the subsystem ant' includes; the subsystem 
name, the requirements associated with it, data types, vari- 
ables, and constants used within it. 

Modules are basic system objects in an SSL system 
do.scr ipt ion . In Figure 2-5, we present a portion of the SSL 
grammar for module descriptions. A correspondence between the 
module items identified by SSL and the specific statements used 
to implement these are shown below: 



Module Item 

SSL Statement 

• 

module name 

MODULE, ENTRY 


input data 

USES 

• 

output data 

CREATES, MODIFIES 

• 

conditions placed on 
data upon entry to and 
exit from the module 

ASSUMES, SATISFIES, 

• 

dependence on environ- 
mental objects and other 
modules 

ACCESSES, EXECUTES 

• 

requirement attributes 

FULFILLS 


In Figure 2-6, we present 

a simple example of SSL 

s i gn 

for a module. 
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MODULE 


ENTRY 




< MODULE NAME > ; 


ASSUMES 

FULFILLS 

USES 

ACCESSES 

CREATES 


< ASSERTION LIST > ; 

< REQUIREMENT LIST > ; 

< DATA OBJECT LIST > ; 

< ENVIRONMENT OBJECT LIST > ; 

< DATA OBJECT LIST > ; 

[ USING < DATA OBJECT LIST >] 


MODIFIES < DATA OBJECT LIST > ; 

[ USING < DATA OBJECT LIST >] 


EXECUTES < MODULE NAME LIST > ; 

SATISFIES < ASSERTION LIST > ; 


Figure 2-5. 


SSL Skeletal Definition for Modules 


JiLE SORT (NiIKEEEER) j 

r MODULE TO SORT ARRAY 

r ARRAY IS INITIALIZED FROM CARD READER V 


ASSUMES 

FiiLEILLS 

ACCESSES 

MODIFIES 

SATISFIES 


N > 0 j 
ORDERED „ VALUE; 
CARDJfADERj 
SARRAY USING N; 

EQSALL (I; INTEGER ) 

I > 0 MU I 1 N-1 
AH 

SARRAY [I] ^ SARRAY 0+1] 


Figure 2-6. Description of Module in SSL 
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2.4 LANGUAGE DESIGN FOR RELIABLE PROGRAMS 

The consistent production of reliable coinputer programs 
makes stringent demands upon the selection of the programming 
language employed. For example, to minimize the effort required 
to carry out a program proof of correctness, the language con- 
trol structures should be as simple in concept and as few in 
number as possible. To produce programs that are clearly 

understood and easily modified, one should construct code in 
modular units using the top-down philosophy. We suggest the 
following attributes as being worthwhile goals in the selection 
of a machine processable language: 

• Simple to use 

• Easy to understand 

c Quickly Machine Processable 

c Reliably Machine Diagnosible 

« Translatable into Efficient Machine Code 

These general language attributes have direct implication upon 
the structure of the programming language employed. Some of 
these implications are as follows: 

• The language should follow naturally from a 
top-down approach and should be able to reflect 
the problem at hand 

• The language promotes a sequential implementation 

• Control structures should be clear and explicit 
and should be kept to a minimum 

9 The language should exhibit the same syntax 

structure for semantically similar constructs 
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The language should allow indentation and a 
type of modularization that clearly defines 
the boundary of each module and allows each 
module to be clearly and completely locally 
understood 

The language should have meaningful reserved 
words 

The language should allow the programmer to 
write often used constructs with a minimum of 
detail 

The language should offer a non-restrictive 
placement of comments which facilitates 

trouble free usage 

Side effect changes of data should be made 
explicit and restricted to a minimum 

Data types and other information crucial to 
correct execution should be explicitly specified 
preferably in several different ways 

The language should have context-free syntax 

The language should allow amenability to auto- 
matic code analysis tools 

Machine overhead of often used constructs 
should be kept to a minimum 
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Maximal compatibility with FORTRAN - the language most used by 
NASA - demands that we try to achieve the above language goals 
through a structured FORTRAN preprocessor. The central struc- 
tures of the preprocessor are being designed to include the 
above features. A full description of this preprocessor will 
be included within a follow-up contract. Along with the pre- 
processor, a programming methodology is being formulated 
which pinpoints questionable coding practices, for it is quite 
possible to construct poor software with the best of languages. 
Many of these practices are defined in subsection 2.5 (and also 
2.5.1) on static analysis. 
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2.5 STATIC CODE ANALYSIS 

A static analyzer for ANSI FORTRAN code accepts source ; 
program code as input and evaluates the code in a static manner, | 
i.e,, the program being checked is not in execution. A static | 
analyzer can be used to accomplish a variety of functions. 

After combining our ideas of static analysis with those in the 
available literature E 2 1 — [ 6 ], we Identified three areas into 

which all the functions of a static analyzer can be classified: 

• Reliability Enhancement 

The static analj'^zer could enforce technical i 

j 

coding standards, i.e., the identification and 
characterization of critical areas and items in 
the code which are likely candidates for incon- 
sistencies and errors. The NASA tool FACES is 
directly concerned with this function. 

• Verification Determination 

The functional specifications written in SSL 
(Software Specification Language) can be verified 
by a static code analyzer, i.e., the consistency 
of the program code with certain specifications 
can be checked. This static verification could 
compare variable and module interconnections of 
the program with SSL specifications. 

• Documentation Assistance 

The documentation of pertinent program informa- 
tion, which will be used during the code test- 
ing/debugging and maintenance phases of the soft- 
ware development, can be provided by a static 
code analyzer. 

Pertaining to reliability enhancement , we constructed 
in Table 2-2, a list of catagories for source code program check- 
ing. 



2-27 


Table 2-2. Source Code Program Checks 

A. Syntactical and semantic checks which 

involve evaluation by element, express- 
ion, and statement 

B. Logical structural checks which involve 

analysis of the program as a single entity 
and of the entire system of programs as 

a whole 

C. Machine independence checks 

D. Clarity enhancements (such as requiring 

nested DO loops to have unique targets) 
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Performing these checks would provide a comprehensive source 
code analysis as to style, format, and structure. As illus- 
trated in the following subsection, our efforts in static 
analysis have been concentrated in this area. 

In reference to verification determination , we ascer- 
tained that the effort necessary to incorporate the capability 
of matching source code with SSL specifications was beyond the 
.scope of this contract. However, we recommend this task for a 
future project since it would represent a significant step to- 
ward automated software verification. 

We believe that a static code analyzer could expedite 
the code maintenance process by providing a comprehensive pro- 
gram report consisting of the items in the following table. 

Table 2-3. Program Report Items 

A. Language element categorization 

B. Subprogram cross reference listing 

C. Variable usage (i.e., type) inconsistency flags 

D. COMMON summary 

E. Variable or array initialization summary 

F. Special variable role summary 

• Adjustable array dimension 

• DO loop control variable 

• Assigned GO TO variable 

m Computed GO TO variable 

• Input /output unit designator 

G. Input/output reference summary 

However, due to higher SSES priorities, implementation of this 

aspect of static analysis is not currently planned. 

2.5.1 Static Code Analyzer Enhancements 

During the contract period, documentation for the NASA 
tool FACES (FORTRAN Automated Code Evaluation System) became 
available.. Shown in Table 2-4 are the capabilities currently 

J;/— 
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Potential cyclic calling patterns 
among routines are flagged 

A DO loop index can not be used 
outside the loop 

A DO loop variable or parameter 
should not be redefined within 
the loop 

Function subroutines should not 
alter input parameters 

Two-way, three-way, IFs and 
computed GO TOs should have the 
next sequential statement as one 
of the targets 

An uninitialized variable and 
array element search is performed 

Occurrences of local variables 
in assignment statements are 
flagged 




featured in FACES. New capabilities deemed desirable and feasi- 
ble by NASA and SAI are shown in Table 2-5. The detailed speci- 
fications for incorporating these new capabilities into FACES are 
provided in Part II of this final report. 



TABLE 2-5 NEW PACES CAPABILITIES 


EQUIVALENCE and EXTERNAL statements are flagged. 


COMMONS not named are flagged. 


ALL COMMON BLOCK arrays must be dimensioned in 
COMMON BLOCK statements. 


DIMENSION statement and variable which contain 
an adjustable (variable) dimension are flagged. 


Constants, hollerith, or arithmetic expression 
arguments used in subroutine argument lists are 
flagged. 


All occurrences where the same variable exists in 
multiple positions in an actual parameter list are 
flagged. 


Targets of branches should not be other branches, 
especially single GO TOs. 


TABLE 2-5 NEW FACES CAPABILITIES (Cont.) 


Variable which is I/O unit designator is flagged. 


Statement labels must appear in increasing order. 


Arithmetic IFs are flagged. 


Occurrences of error-prone FORTHAN statements such 
as ASSIGN statement, assigned GO TO, and PAUSE are 
flagged. 

The appearance of the same COMMON variable in more 
than one DATA statement is flagged. 
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DATA BASS VERIFICATION 
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The problem of verifying the structure and contents of 
a stored data base (i.e., the part of a data base which resides 
on permanent storage) is difficult. However, the problem be- 
comes more complex when it is coupled with the task of ensuring 
the continued integrity of the stored data base throughout ac- 
cessing and updating operations. Since the late 1960 's the 
CODASYL (Conference of Data Systems Language) and other orga- 
nizations have been engaged in the formalization of their ap- 
proach to these and other problems concerning data bases [7] . 
The CODASYL has directed its efforts toward developing language 
standards for describing extensions to existing high level lan- 
guages (such as FORTRAN) which will allow access and operation 
on the data base components as well as describe the part 
of a data base which resides on permanent storage. 

As background for discussing our approach to data 
base verification, we present CODASYL 's view of a data base 
management system. A data base management system is a system 
which manages and maintains data in a nonredundant structure 
for the purpose of being processed by one or more applications - 
In the environment depicted in Figure 2-7, an applications 
programmer writes a program in a high order programming language 
such as FORTRAN or COBOL which has been extended to incorporate 
Dat a Manipulation Language (DML) commands. The DML statements 
are data base access mechanisms, i.e., they provide application 
program interfaces to the data base during execution. (Note: 
CODASYL 's usage of the term "data base" is the same as our def- 
inition of stored data base. ) 

A schema DDL (Data Description Language) completely de- 
fines the data base; it includes the names and descriptions of 
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'BUILT AND MAINTAINED BY THE DATA BASE ADMINISTRATOR 


Figure 2-7. Archiioclure of a CODASYL Data Base Managernont System 


lid 

Q 

m 

Eq 

•ri 

O 

O 



REPRODUCIBILITY OF THE 







id 




O' 




all thf> areas, set types, record types and associated data 
items and data aggregates as they exist in the data base CaD 
and are known to the data management programs. However, an 
app I i c:a t i ons program must be concerned with the description of 
only that part of a data base which is useful and meaningful 
to It. This description is called a subschema. A subschema is 
a subset of a schema which allows the applications program to 
view only those portions of the data base declared necessary 
for that particular program. Therefore, the remainder of the 
data base is insulated from the execution of an applications 
program or a subsystem of programs. The characteristics of 
the data items (and the arrangement of items within records ) 
described by the subschema may be different from the character- 
istics of those data base items defined by the schema. Since 
a program depends only on the subschema for data base infor- 
mation, changes may be made to the schema of the data base and 
the data base may be appropriately adjusted without affecting 
the programs using the data. Correspondingly, a subschema may 
be modified to provide compatibility with a specific program- 
ming language, and the schema will not be affected. 

The actual mapping or conversion of subschema descrip- 
tions to schema definitions is performed by the data base man- 
agement system (DBMS). (The subschema contains the mapping 
definition which specifies the correspondence between the sub- 
schema and schema. ) Thus a degree of data independence is e.s- 
tablished by employing the schema and subschema mechanisms. At 
the same time, flexibility in the choice of programming lan- 
guages is supported since that part of a data base known to a 
program can be described according to any particul'r program- 
ming language conventions. 

For each application program, there is defined a user 
working area (UWA) which contains locations lor all data de- 
livered to the program from the data base and vice versa. The 
program refers to these locations via names in the subschema. 
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In fact, the UWA is set up by the DBMS according to the sub- 
schema which is evoked by each appl icat ion program [9]. 

In the process of creating and maintaining a data base 
management system, the need for human involvement becomes ap- 
jiarent. The human activities are performed by the data base 
administrator (DBA). According to CODASYL, the DBA is respon- 
sible for; 

o Writing the schema and subschema 

• Modi fying the schema and subschema to 

reflect changing user needs 

» Designing, assembling, and loading the data 

base 

o Monitoring the use and performance of the 

data base and reorganizing the data base for 
greater performance efficiency if required. 

o Assigning data to physical devices 

0 Assigning privacy locks and issuing privacy 

keys to users for specific portions of the 
data base 

0 Recovering the data base after system malfun- 

ct ions . 

.Sinc(? the DBA is respon.sible for data management as indicated 
by the above functions, the application programmer is relieved 
ef this retsponsibi 1 i ty and can concentrate on other aspects of 
programming . 

This discussion of the interworkings of the DBMS 
rnmpononts provides a basis for a series of data base veri- 
f ic;aLi<jn subsystems which when integrated would form a data 
[)jis(‘ verification system. The data base verifier that we de- 
si gru'd ran be considered as one of these subsystems. Our data 
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ba«G verification subsystem concentrates on the FORTRAN appli- 
cations program which, according to CODASYL, must be written 
in ANSI FORTRAN that is extended to incorporate Data Manipu- 
1 a Li on Language (DML) commands. 

As input, our data base verifier accepts CODASYL FORTRAN 
Data Manipulation Language. The specifications for this lan- 
guage are still being refined and will not be finalized until 
the end of this calendar year. However, we obtained a CODASYL 
FORTRAN Data Base Facility Journal of Development which was 
printed on November 25, 1975. Though this document is only a 
working paper for the FORTRAN Data Base Manipulation Language 
Committee, we used it as the foundation of our design, since 
the basic problems to be analyzed and solved will remain con- 
stant though the syntax may be altered by the committee during 
the refinement stages. 

A brief summary of the functions of our data base veri- 
fier are the following; 


Accepts FORTRAN DML source code as input 


a Statically analyzes the program and constructs 

tables which describe the stored data base that 
the program accesses and manipulates 

e Prints a summary of all the information 

collected about the components and the 
structure of the stored data base. 


Th(’ user must then establish the consistency and validity of 
the stured data base within the framework of the program de- 
HrripLit)ns by cross referencing these tables. A future en- 
hanc-.ement to our data base veri tier includes the automatic con- 
si st.ency checking f)f the.se data base descriptions as set forth 
l)y the applications program. Part II of this report contains 
Cuuc'tionai specifications (i.e., SSL descriptions) of the data 
* veri Tier siih.svst cm . 
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GRAPH ANALYSIS AND INSTRUMENTATION 


The key to most program analysis systems is the selec- 
tion of a model which yields the correct program characteristics 
to base analyses on. The standard approach that is used 
in systems built for software testing is to use a program-graph 
model. We will describe the general process of formulating a 

prt>gram-graph , and present the pertinent manipulations which 
support a dynamic analysis system. In the first section, the 
procedure for forming the program-graph is described. The next 
section contains a description of DD-PATHS in a program-graph. 

2.7.1 The Program Graph 

A program-graph is formed from a program unit (main 
procedure or subroutine) by mapping selected program statements 
into node.s and corresponding edges. To illustrate the program 
graph construction, we present in Figure 2-8 an exhaustive de- 
compfisit ion of the elements in the ANSI FORTRAN. This type 
of language construction could be carried out for any language. 
Tfu; sot of abbreviations on the right hand side serve a two- 
fold j)urposo: (1) they identify the particular .statement types 

1 lull mu.st bo addressed: (2) they provide a convenient short form 
lo refer to each of these statement types. Note that compound 
IF statements are completely decomposed in this table so that 
all constituent parts can be identified; for example, IF5 re- 
ier.s to a statement of the form 

IF (logical expression) IF (arithmetic expression) n,m,p. 

The set of FORTRAN elements directly referenced in Fig- 
ure? 2-8 are the only elements which are mapped into the program- 
graph. 

There are nine mapping formulae. In each of these cases 
t lw‘ state>mcnt is mappt.d directly into a node; decisions are made 
only (.-onrorning the formation of edges from that node. 
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• Executable 


• Assignment 


e Arithmecic 

AS! 

• Logical 

AS2 

B GOTO 

AS3 

■ Control 


• GOTO 


B Unconditional 

GOl 

0 Assigned 

GOZ 

B Computed 

G03 

• IF 


9 Ari thmeti c 

IF! 

• Logical 

- * 

• Simple 


S With GOTO 

IF2 

9 With RETURH 

IF3 

0 Other 

IF4 

9 Compound 


• With Arithmetic IF 

IF5 

B With Computed GOTO 

IF6 

9 With Assigned GOTO 

IF7 

• CALL 

CAl 

B RHURN ot- END 

REl 

a CONTINUE 

COl 

a STOP or PAUSE 

STl 

• DO 


s With Unique Terminal 

DOl 

a With Shared Terminal 

D02 

a I/O 

1— 1 
o 

a Non-Executable (Headings) 


a Main Program Implicit Begin 

HE! 

a SUBROUTINE 

HE2 

a FUNCTION 

HE3 


Fitiure 2-8. ANSI FORTRAN Statement Table 
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1 . 


Direct Sequential. Single : A single edge is formed 

between the given node and the next sequential node. 

2. Direct Sequential. Double : Two edges are formed as 

in #1. 

3- Termination : A single edge is formed to the design- 

ed terminal node. 

4. Direct Defined, Single : An edge is formed between 

the given node and another node specified as its 
target . 

5. Direct Defined, Multiple : Several edges are formed 

as in #4 . 

6. Mix 1-4 : Two edges are formed; one as in #1, the 

other as in TT 4 . 

7. Mix 1-5 : Several edges are formed; one as in #1, 

the others as in #5. 

8. Mix 1-3 : Two edges are formed; one as in "1, the 

other to a node designated as the terminal (as in 
# 3 ) . 

9. Loop : Three edges are formed; one as in #1, the 

second from a designated target node back to the 
given node, and the third from a designated target 
node to another designated target node. 

In Figure 2- 9, the elements in the statement table are matched 
with their corresponding mapping formula. Note that the map- 
ping formula simply follow the potential flow of control from 
each statement. Formula #9 is used for the DO statement; the 
third edge connects the DO target with the statement which is 
executed once the DO is satisfied. 

The FORTRAN DO statement, following ANSI documen- 
tation. is expected to behave so that the loop index is set to 
the first parameter, the loop i.i .-.Vv’cuted. and then the index 
incremented and checked against the terminal parameter. In this 
fashiOHj it appears that control is centered in the DO target 
statement rather than the DO itself; hence, the edges ;ie formed 
as described in #9. 


Foi-mula. 


El ements 


7. Direct Sequential, AS! -3, CAl, COl, STl , IDl, 

Single HE! -3 TlF NONE OF THE ABOVE 

ARE THE DO TARGET — IN WHICH 
CASE #9 APPLIES] 

Z. Direct Sequential, IF4 

Double 

3. Termination REl 

4. Direct Defined, GOl 

Single 

5. Direct Defined, G02, G03, IH 

Multiple 

6. Hi:< 1-4 IF2 

7. MiJt 1-5 IF5, IF6, IF7 


8. Mix 1-3 IF3 





The program-graph is formed In a two stage process. The 
lirsL stage involves the lexical scan of the program and the 
iclc'nl, i rtcation of statement type and aiixiliary pointers. These 
pointers reference the node(s) to which the given node is to he 
ronnoctod when such nodes are not the next sequential node num- 
b(.'r. Consider as an example the statement 

IF (A.GT.B) IF (C) 10, 20, 30 

which in this scheme would be identified as IF5 ; the pointers 
which must be determined are three in number; pointer to the 
node which corresponds to label 10, the same for label 20, and 
for label 30. 

The DO loop poses special problems since the target 
statement takes on the semblance (from a program-graph view- 
point) of a control statement. The usual procedure for a DO 
is then to identify the target statement via a pointer. Some 
confusion arises when several DO statements share a common tar- 
get (D02); hence^ it is recommended that in this case, an arti- 
ficial target is added to allow only DOl^s to occur in the pro- 
gram . 

The program-graph for a sample program. Figure 2-10, is 
shown in Figure 2-11 . 

2.7.2 DP Paths 

The program-graph representation accurately reflects 
the control flow within a program. It is also the case that 
there is a reduced form for the program-graph which also cap- 
tures that control flow. The DD Path program-graph is formed 
from the program-graph by collapsing linear segments of the 
structure. A linear segment is a series of nodes which have 
a single edge in and a single edge out. 
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Text 


No. 

SUBROUTINE SAMPLE 

HE2 

1 

SET = SET + 1 . 

AS! 

2 

ASSIGN 10 TO LABEL 

AS3 

3 

GOTO LABEL 

GOl 

4 

20 CALL OUT 

CAl 

5 

IF (EXP) 20,30,40 

IF! 

6 

30 SET = SET + 2. 

AS! 

7 

IF (EXPl) GOTO (10,20,30,40), I 

IF5 

8 

GOTO 20 

GOl 

9 

10 ZSET = ISET + 3 

AS! 

10 

CALL OUT 

CAl 

n 

DO 50 0 = 1 ,9 

D02 

12 

SET = SET + 1 . 

ASl 

13 

DO 50 K = 5,6 

D02 

14 

CALL OUT 

CAl 

15 

•50 CONTINUE 

cm 

16 

GOTO 20 

GOl 

17 

40 RETURN 

REl 

18 


Figure 2-10. Sample Program 



Figure 2 - 11 . Program-Graph for Sample 



The flow of control within a program is induced by the 
prog7 am branches; likewise the flow within a program-graph is 
induced by the branch nodes (nodes with more than a single em- 
anating edge). A DD Path is a path in the program graph which 
begins and ends on a decision node (D node). The D nodes are 
the branch nodes, the entry node, and the terminal node; in 
the sample program-graph (Figure 2-11) the D nodes are: 

1, 6 . 8, 16, IS 
corresponding to statements 

HE2, IFl, IF5, COl (D02),RE1 

The table iu Figure 2-12 is the collection of DD Paths 
for the sample program-graph. The DD Path graph is shown in 
Figure 2-13. 

Each DD Path begins with a decision node; however, the 
actual path is a collection of edges and each edge corresponds 
to an outcome from a node. A DD Path is, then, representative 
of a set of outcomes from each D node; there is a condition as- 
sociated with the selection of each DD Path. The contents of a 
DD path are simple to derive, and since all but the first node 
have only one successor node, it is easy to describe each DD path 
by its constituent nodes without loss of information. 

A point to be discussed in the next subsection is that 
the DD Paths are identified by numbers and the numbers are as- 
signed in a manner which is unique (it can be relied upon to 
give the same numbering each time). This numbering algorithm 
is the following: 

1. Order the DD paths by their initial node 

2. Within each group of DD paths with the same 
initial node order the elements by their cor- 
respondence to the D node decision outcome. 

The ordering by outcome is: 
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DD PATHS 




Ho. 

From.’To 

Contents 

Condition 

1 

1:16 

1 - 2 - 3 - 4 - lD - n - lZ - 

13 _ 14 ^ 14_16 

entry 

Z 

6:6 

6 - 5-6 

EXP .LT. 0 

3 

6:8 

6 - 7-8 

EXP .EQ. 0 

4 

6:18 

6-18 

EXP .GT. 0 

5 

8:16 

8 - 10 - 11 - 12 - 13 - 14 - 

15-16 

EXPl .EQ. TRUE 
.AND. I .EQ. 1 

6 

8:6 

8 - 5-6 

EXPl .EQ. TRUE 
.AND. I. EQ. 2 

7 

8:8 

8 - 7-8 

EXPl -EQ. TRUE 
.AND. I. EQ. 3 

8 

8:18 

8-18 

EXPl .EQ. TRUE 
.AND. I. EQ. 4 

g 

8:6 

8 - 9 - 5-6 

EXPl .EQ. FALSE 

10 

16:16 

16 - 12 - 13 - 14 - 15-16 

DO Q 12 Loop 

11 

16:16 

16 - 14 - 15-16 

DO @ 14 Loop 

12 

16:6 

16 - 17 - 5-6 

DO nest completion 


Figure 2-12. DD Paths for Sample 









Figure 2-13. DD Path Graph for Sample 
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2.1 True before False 

2.2 If there are several trues (or falses) 
order them by the lexical order of their 
target definitions in the original program 
statement . 

For example, the statement 

IF (EXPl) GOTO (10, 20, 30, 40), I 

in a program would obviously have 5 DD paths stemming from its 
assigned node; these paths would be ordered by 


a . 

EXPl 

.EQ. 

TRUE 

.AND. 

I 

.EQ. 

1 

b. 

EXPl 

.EQ. 

TRUE 

.AND. 

I 

.EQ. 

2 

c. . 

EXPl 

.EQ. 

TRUE 

.AND. 

I 

.EQ. 

3 

d. 

EXPl 

.EQ. 

TRUE 

.AND. 

I 

.EQ. 

4 

e . 

EXPl 

.EQ. 

FALSE 






Aside from the above description of the ordering pro- 
cedure as external source views it, there is a simpler internal 
description. Since statements are scanned sequentially in order^ 
the edge list is formed in order by beginning node number. The 
edge list for a single node follows from the lexical scan so 
that in, say, the above example a, b, c, d are in the natural 
order. Since the edge list is already ordered, the DD Paths 
are created in the desired order by simply using the edge list 
and assigning DD Path numbers in a sequential fashion starting 
I'rom the first D node in the edge list. 

To clarify the above "simpler" internal description, 
<’on.sider the edge list for the sample program. The first sev- 
eral entries of their list would be 

1 to 2 

2 to 3 

3 to 4 

4 to 10 

5 to 6 
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6 to 18 

7 to 8 
etc . 


beproducibility of the 
O mOlNAL PAGE IS 


The D nodes, as presented earlier, are 1, 6, 3, 16, IS. 
DD Paths would be, then, 

1 to 2 to . . . nl 

6 to 5 to . . . n2 

6 to 7 to . . , n3 

6 to 18 
etc . 


The above sequence of DD Paths obeys the external order stand- 
point, although it is created from purely straightforward de- 


vices . 


2.7.3 Probe Numbers and DD Paths 


graph . 


One probe is placed for each DD Path in the program- 


The probe numbers are the DD Path numbers. See the 


following subsection for a complete discussion of probe place- 
ment algorithms. 

2.7,4 Instrumentation Templates 


A software probe is a CALL to an auditing subroutine; 

(ho subroutine, in turn, records the identity of the actual 
probe which evoked it. 

Probes are placed in the software so that they can inter* 
ropL the passage of the program control point. Since paths are 
induced in the program by the branch statements^ it is neces- , 
.sury to position probes only at those branch points. (The ex- 
ceptions to this rule are the entry and exit points from the 
program which are advantageous to probe. ) 
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The placement of probes is carried out by a macro-ex- 
pansion technique for each branch point in the program. As 
fa<>h branch point is determined the branch is replaced (expand- 
ed) into a composite program segment which incorporates a probe 
without loss of the logical capability of that branch. For 
example, the statement 

IF (X .EQ. Y) A = B+C 

would be expanded into 

IF (X -EQ. Y) GOTO 99 
CALL PROBE (*) 

GOTO 98 

99 CALL PROBE (*) 

A = B+C 
98 CONTINUE 

2.7.4. 1 ANSI FORTRAN Branch Statements 

ANSI FORTRAN branch statements can be considered in 
two classes: simple and compound. The simple statements are 

DO 

IP (-THEN) 

IF-ARITHMETIC 

COMPUTED-GOTO 

ASSIGNED-GOTO 

The compound statements involve the combination of an IF (-THEN) 
with another branch statement; the most straightforward type to 
handle is 

IF-COMPUTED-GOTO 
IF- ASSIGNED-GOTO 
IF- IF-ARITHMETIC 
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For convenience^ we will treat branch statements in the groups 
closer i bed above - 

The macros for the given FORTRAN statement types in- 
volve the use of auxiliary statement labels. It is assumed 
that a facility will be maintained which will assign these 
labels so no program conflicts arise. For the examples shown, 
these auxiliary labels will be given numbers decending sequen- 
tially from 99999. 

The exact nature of the arguments which are passed in 
the probe envocation is not described in this paper; hence the 
pnjbe CALL will be noted simply by the key word "PROBE.” 


A. DO 

DO [label] [index] = [n], [m], [o] 

[label] [statement] 

3|c 4: ^ 

DO [label] [index] = [n] , [ra] , [o] 

PROBE 

[label] [statement] 

PROBE 

B. IF (-THEN) 

IF [expression] [non-branch statement or 
simple goto] 

+ + + * + 
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IF [expression] GOTO 99999 
PROBE 

GOTO 99998 


99999 PROBE 


[non-branch statement or simple GOTO] 


99998 CONTINUE 


C. IF-ARITHMETIC 


IF [expression] [label-a] , [label-b] , [label-r] 




IF [expression] 99999,99998,99997 


99999 PROBE 


GOTO [label-a] 


99998 PROBE 


GOTO [label-b] 


99997 PROBE 


GOTO [label -c] 


D . COMPUTED GOTO 


GOTO ( [a] , [b] 


[t emp] 




[index] 


PROBE -SPECIAL 


[z] ). [index] 


GOTO ( [a] , [b] . ... , [ 2 ] ). [temp] 

Note. Since the value of [index] must be an integer and since 
f)rnbf's are assigned integer identification numbers, then it is 
straightforward to create the situation where the probe number 
■ -in bo computed using [index] . The PROBE-SPECIAL is a probt 
ev()<-:itif)n which takes into account the value of [index]. 
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ASSIGNED GOTO 


GOTO [index] , ( [a], [b], ...,[z]) 

^ 

[temp] = [index] 

PROBE-SPECIAL 

GOTO [temp], ([a], [b] , ... ,[z]) 

F. IF-COMPUTED GOTO 

IF [expression] GOTO ([a-] . ••• i [z]), [index] 

IF [expression] GOTO 99999 
PROBE 

GOTO 99998 

99999 [temp] = [index] 

PROBE- SPECIAL 

GOTO ([a] [z]), [temp] 

99998 CONTINUE 

G. IF-ASSIGNED GOTO 

See B and F for obvious solution. 

H. IF-IF-ARITHMETIC 

See B, C, and F for obvious solution. 
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DYNAMIC ANALYSIS 


REPRODUCIBILiTY OP THE 
ORIGINAL PAGE IS POOR 


2.8.1 Introduction 

Implementation of an automatic code analysis tool can 
be carried out using the theory developed in subsection 2.7. 
Such an analysis tool would monitor code execution and would 
be capable of performing the following functions: 

0 Indicate unexercised code segments 

• Indicate execution statistics for exercised 
segments within each module 

• Indicate execution statistics for whole modules 

o Monitor variable principal values and the point 

within the code these values were attained 

These functions would be supplied through probe information 
.supplied by the user. A tenative description of how the user 
might interface with a dynamic analyzer is described below. 

2.8.2 User Interface 

The dynamic analysis tool would have two main oper- 
ational parts. The first part performs syntactic analysis for 
instrumentation purposes; the second processes and interprets 
the instrumentation (run-time) data. Due to this natural 
organ izat ion_, it makes sense to partition the user interface 
along the same lines. 

The user interface facilities are: 

0 Commands 

Probe Placement (instrumentation) 

Variable Value monitoring 

Reporting Options 

& Reports 

Archival Listing 

- DDP Identification 
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- DDP Conditions 

- Variables Codes for Reference 

Coverage Reports 

- Effectiveness of Module Testing 

- DDP Coverage Per Module 

- Variable Value Information 

User commands are processed during the first phase 
(syntactic analyses) and the appropriate capabilities added 
to tho Mirget program. THE USER WILL BE GIVEN THE ADDITIONAL 
FEATURE OF SOURCE LANGUAGE SELECTION — ANSI FORTRAN OR 
STRUCTURED FORTRAN. 

According to user commands the archival listing will 
incorporate ALL syntactic information so that reports can 
reference DDPs by number, and variables by a symbolic name (or 
code ) . 

The advantage of this approach is there is no need to 
save any syntactic program information to carry out a complete 
coverage analysis. The user can refer to the archival list- 
ing for all collaborative information, i.e,, DDP elements, DDP 
<;onditions, actual variable names, etc. 

2,8.3 Commands 
PROBE module name 


This command causes the indicated program module to 
bo instrumented for coverage purposes. Module_name equal to 
"MAIN” causes the main program to be instrumented (FORTRAN 
only); "ALL" causes all procedures, subprograms^ and functions 
to be probed. 

MONITOR variable name (type) [iN module_name] 


2-55 


Jj/ 


This command will monitor the principal values of the 
indicated variable at all DDP control points in the specified 
module. MAIN is assumed if no module name is given. The 
"type” field must contain the type of the variable in the 
mfjdule (INTEGER, REAL, LOGICAL, etc.). The specified module 
must have been instrumented (explicitly or implicitly) by a 
PROBE command. 

SELECT (ANSI FORT or STRFORT) 


Indicates whether an ANSI FORTRAN or structured 
FORTRAN is being analyzed, 

NOLIST module name 


Suppresses the archival listing for a particular 

module . 

NOSUMMARY module_name 

Suppresses the test effectiveness summary for a 
particular module, 

REPORT module_name [VARIABLES] 


Causes the printing of a detailed DDP coverage report 
for the indicated module, with or without variable monitoring 
information (see below). 
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R(; ports 


Figures 2~14, 2-15, and 2-16 show sample formats of the 
v:irt(jus reports. 
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MODULE TESTING EFFECTIVEHESS SUMMARY 


MODULE 

TIMES INVOKED 

# DD PATHS 

^EXECUTED t 

COVERAGE j 

XXX 

1 

7 

5 

71.5 1 

xxxx 

2 

5 

3 

60.0 

xxxxx 

7 

3 

3 

100.0 


TOTAL 

15 

n 

73.5 

(AT LEAST DNCn 



! 


Fi{j;in’f‘ 2-15. 

Summary 

Ropni t S.'impl o 



DETAUE D T F<^ T REPORT MODULE xx xxx 


MODULE 

xxxxx WAS 

INVOKED 

1 TIME 



DD PATHS 

TOTAL 

COVERAGE 

PROFILE 






(PercEiil Execumd) 

100% 

1 


10 


■A* 


2 


20 




3 


10 




4 


10 


** 


S 


50 


•A * it* ****** 


6 


0 




7 


0 




TOTALS 






7 


100 


PERCENTAGE DD PATHS 71.5 

miAmL 

M{i‘innRiN_G 




CODE 

IHITAL 

FINAL 

MINIMUM 

MIN DDP MAXIMUM 

MAX DDP 

] 

1 

0 

0 

0 

1 5 

4 : 

2 

17.6 

-3.05 

-20.6 

1 17.6 

1 ! 

3 

TRUE 

FALSE 



" f 

FU 

iur<' 2- 

-Ifi. 

Dc*ta i 1 f?d 

Modulo To.st 

Rcpfirt 




FikHir*' 2-lfi. 
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‘A, a AUTOMATIC TEST CASE GENERATION 

2.9.1 Testcase Generation Functions 

The theory presented in section 2.7 helps form the basis 
Tor t.he design of an automatic test case generator. Functions 
performed by this automatic tool would include: 

• Facility to indicate input variables of the 
program 

• Facility to estimate total number of execu- 
table paths 

• Facility to determine a minimal collection 
of paths for execution of all code 

• Facility to determine paths which execute 
selected code segments 

• Facility to generate data to exercise specific 
code segments 

The first three capabilities can be obtained directly through 
the graph formation and manipulation techniques described in 
in section 2.7. The last two capabilities are more difficult 
and, in a certain sense, impossible. We shall describe the 
sense in which an automatic test case generator can assist the 
user in generating test data. 

2.9.2 Language Considerations 

The test case generator would work optimally on pro- 
grams written in a well designed language. The basis of such 
a language, in the form of a structured FORTRAN preprocessor, 
has been formed in section 2.4. The control structures of 
Lhsil language were chosen to insure clarity and minimality, 


fd 






M, 




$ 


f 




whilo retaining as much of the versatility and compactness of 


Lho original FORTRAN as possible 
FORTRAN DO loop is replaced by 


FOR 


^ 1 ’ ^2 


For example, the ordinary 


[ij 


code 


END FOR 


As opposed to FORTRAN, this loop executes if and only if ±2 is 
greater than i^. In a similar way, if one uses a well designed 
language, all segments of code are associated with a particular 
condition either on control indices and/or program variables. 
(Such conditions are, in fact, recorded in the archival list- 
ing of the dynamic analyzer.) The testcase generator uses all 
the conditions associated with a particular path to attempt to 
generate input data to exercise that path. If one choose a 
particular module within the code, the testcase generator 
attempts to determine feasible paths which reach from a pro- 
gram input position to that module; and next it attempts to 
generate data to exercise that path. We need to emphasize here 
that building a program to guarantee solving a system of sim- 
ultaneous equations and inequalities is theoretically impossible 
However, a program can be built which in most cases can suc- 
ceed in generating at least one set of correct data. 

2.9.3 Theoretical Foundations 

A new approach to program testing, called symbolic 
exec'.ution [lo] could help form the basis for a testcase gene- 
rator. It describes, in terms of original input variables, the 
actions of the program's successive processing steps. Assume 
input variables to be x^... x^^ and that after k processing 
steps, the first branch statement is reached, v/hich in terms of 

X, . . , X is of the form 
L n 
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IF 

F (x^ 

- X 

„) 

.GT. 

0 


THEN 

GO 

TO 

20 

BKPRODUCIBILITY of TI-l*i 


ELSE 

GO 

TO 

30 

ORIGB^AL PAGE IS POOR 

END 

IF 





The testcase 

generator tries 

one 

acceptable input value of the 

vf?ctor . . . 


ai- 

- * 3. 

n 

. If 

F(a^...a^)>0 we would attempt 


1o alter so that F<0, to exercise the other side of the 

branch. To do this we would, compute the negative gradient of 
F, -dP(Xj^ - x^) andj to decrease the value of alter a^^ - a^ by 
a vector of a predefined length in the directon of -dF(x^ - Xjj). 
The testcase generator again computes F at the new value and 
essentially by the steepest descent method , attempts to find a 
value of aj^...a^ which would make F negative. Thus, using these 
simple techniques, we could construct an automatic testcase 
generator to successively generate data to exercise all program 
path much like a mouse finding its way through a maze; but 
t,hr> implementation of such a testcase generator has yet to be 
(‘iirri<?d out. 
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2.10 SOFTWARE REQUIREMENTS TESTCASE GENERATOR 

The conception of a computer program - at the require- 
.stage ~ should be an optimal time for the establishment 
of most benchmark testcases by which the program can be fair- 
ly assessed. Through two SSES methods already presented we 
reel the automatic generation of test cases from software re- 
quirements is a realistic possibility. 

Recall that one of the principal features of the Soft- 
ware Specification Language (cf. section 2.3) is the fact that 
it tags all software modules with the particular requirements 
which that module was constructed to fulfill; thus it physi- 
cally maps requirements into the software. Combining this 
feature of SSL with the way in which automatic structural test- 
case generation can be accomplished, we see that automatic re- 
quirements test case, generation is a distinct possibility, as 
is illustrated in Figure 2-17. In selecting a requirement, 
one, via SSL, also selects all software modules which fulfill 
that requirement. Then, through the use of the automatic 
structural testcase generator, one obtains testcases which 
exercise those modules. Though the implementation of the 
scheme has yet to be carried out, its feasibility seems to 
be clear; we feel its value is obvious. 
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Figure 2-17, Software Requirements Testcase Generation 





3. CONCLUSIONS 


The aim of the work done under this contract was to 
make exploratory studies in a variety of research fields which 
cfjuld potentially make valuable contributions to reliability 
of software. By distilling and summarizing our efforts, we 
obtain the following advocations about building computer pro- 
grams : 

« The software requirements stage (cf. Figure 2-1) 

should result in a structured, formal document 
which leads naturally into thf- software 
specification stage. It should be produced 
by an experienced analyst working in con- 
junction with the user. Origination of key 
software testcases should be an integral part 
of this stage. 

• Software functional design specifications 

should be carried out through a formal lan- 
guage which is capable of reflecting fidelity 
of design with software requirements. 

® Program code should be implemented using a 

structured programming language in which 
control structures are operationally apparent 
and as few in number as tolerable. Hence, a 
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structured preprocessor should be employed for 
code implementation if a structured compiler 
language isn't available. 

• A programming language which promotes standard- 

ization of methods for accessing and operating 
on stored data bases such as the CODASYL Data 
Manipulation Language should be adopted and 
employed for purposes of data base verification. 

« Software testing should be automated to establish 

user confidence while minimizing cost. Both 
static and dynamic testing are required. A 
static analyzer should enforce programming 
standards, while a dynamic analyzer should 
check the reliability of the code during ex- 
ecution. Structural and requirements testcase 
generators would greatly enhance the utility 
of the analyzers. A structural testcase gen- 
erator produces data to test as many branches 
of the code as possible and should be employed 
for determination of software reliability. A 
requirements testcase generator produces data 
to determine the consistency of the code with 
the software requirements. 

m Maintenance documentation needs to be an 

integral part of software. Documentation 
guidelines need to be established. 
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